1. There is no such native setting as Transaction timeout. It starts and ends when user wants.
2. Commands are expected to have either default timeout or the timeout which was set in SessionConfiguration.CommandTimeout. But this behavior treats commands unequally which makes them order-dependent. This inequality makes commands execution untransparent and illogical for the user. Depending on this setting the same query may be executed successfully or failed because some artificial obstacle (because otherwise query would've executed successfully).
3. It interferes with async tokens, which adds even more unpredictability to the equation.
4. This custom behavior is possible to realize without changes in DataObjects.Net code. You have an event for transaction opening to get transaction, you have an extensions collection where you can store whatever you want and you have an event on command executing which gives you DbCommand to set CommandTimeout property (or any other property) as you wish.

4. This custom behavior is possible to realize without changes

Yes, "On events" was our initial implementaion

But after we implemented another feaure "SessionGuard" for detecting concurrent usage of Session, it had a conflict with TransactionTimeout feature, because of order of events.
So the Eventless implementation is necessary for us.

It still conflicts with bunch of other cases. I hardly can allow this. It is very shady in terms of predictability. Maybe we can improve extendibility in a way that will allow you to implement it like a session service or something.

What about sessionhandler replacement?

As I understand you need some code which will work not in context of all sessions, like events do, but in context of one exact session. Am I right?

I did not use SessionHandler, have to learn it.

Regarding to Transaction.Timeout, we need to limit execution time of code like:

var tx = session.OpenTransaction();
tx.Timeout = Timespan.FromSeconds(10);
for (int i = 0; i < N; ++i) {
    // some DO query
}
tx.Complete();